fix(dashboard): Bookkeeping-Events nicht mehr als LLM-calls zählen#73
Open
TillQuandel wants to merge 1 commit into
Open
fix(dashboard): Bookkeeping-Events nicht mehr als LLM-calls zählen#73TillQuandel wants to merge 1 commit into
TillQuandel wants to merge 1 commit into
Conversation
Die Per-Agent-Aggregation (_read_agent_stats + _live_run_data) zählte JEDEN JSONL-Trace-Record als "call" — auch Bookkeeping-Events ohne LLM-Bezug (verifier anchor_stats, critic score_result, orchestrator note_outcome). Folge: der Verifier erschien als "10 calls / 0 Tokens", obwohl er via deterministischem Pre-Pass meist gar keinen LLM ruft (echter Trace: 11 verifier-Records = 1 LLM-Call + 10 anchor_stats). Fix: Helper _is_llm_call_record(r) = "model" in r (Schema-Invariante: _trace schreibt immer model, trace_event immer type, schließen sich aus). In _read_agent_stats per continue, in _live_run_data nur die LLM-Zähler gegatet — Timing/last-activity gilt weiter für ALLE Events (Qwen-Review HIGH: sonst zu früher "letzter Schritt" wenn letztes Event Bookkeeping). Error-Records tragen model und zählen bewusst weiter (echte Calls). Der KPI-Min-N-Guard war bereits im Frontend (n_notes<20) — kein Backend nötig. TDD (4 Tests), Qwen-reviewt, 38 Dashboard-Tests grün.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Beim Mahmood-Lauf fiel auf: das Dashboard zeigt den Verifier mit „10 calls / 0 Tokens / 0.0s" — was wie eine Tracking-Lücke aussieht.
Ursache: Die Per-Agent-Aggregation (
_read_agent_stats+_live_run_data) zählt jeden JSONL-Trace-Record als „call" — auch reine Bookkeeping-Events ohne LLM-Bezug (anchor_stats,score_result,note_outcome). Echter Trace: 11 verifier-Records = 1 LLM-Call + 10 anchor_stats. Der deterministische Pre-Pass (PR #67) verifiziert Anker meist ohne LLM → 0 Tokens ist korrekt, aber die „10 calls" sind irreführend.Fix
_is_llm_call_record(r) = "model" in r— Schema-Invariante:_trace(agents/base.py) schreibt für jeden LLM-Call einmodel-Feld,trace_eventfür Bookkeeping eintype-Feld; beide schließen sich aus._read_agent_stats: Bookkeeping-Records percontinueübersprungen._live_run_data: nur die LLM-Zähler (calls/tokens/dur/errors) gegatet — Timing/last-activity gilt weiter für alle Events (Qwen-Review HIGH: sonst zu früher „letzter Schritt", wenn das letzte Event Bookkeeping ist).model→ fehlgeschlagene Calls zählen bewusst weiter.Nicht enthalten
Der KPI-Min-N-Guard („6 Notes 0% als Headline") ist bereits im Frontend abgedeckt (
n_notes < 20→nWarn, kam mit #59) — kein Backend-Eingriff nötig.Verifikation
test_dashboard_honesty.py)_live_run_datazu aggressiv) + MED (Diskriminator-Robustheit) adressiert; ER-Stage-1-Threshold bei Praefix-dominanten Titeln #2 (Error-Records verlieren model) am echten Trace widerlegt